home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP011793.ARJ / 01-17-93.TPC
Text File  |  1993-01-17  |  76KB  |  2,322 lines

  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       01-12-93 08:12:00
  6. From       Terry Hughes
  7. To         Robert Jambor
  8. Subject    New Library
  9.  
  10.  
  11. RJ>Hello Terry Hughes!
  12.  
  13. RJ> TH> Our Async Professional library already has several such routines.
  14. RJ> TH> APRO 1.10 provides decompression for all LZH 1.0 and ZIP 1.0
  15. RJ> TH> formats; it provides compression for all formats except ZIP
  16. RJ> TH> implode. We are currently working on ZIP implode and LHA 2.0
  17. RJ> TH> support but I don't have an expected release date for those
  18. RJ> TH> items yet.
  19.  
  20. RJ>That's great, (I only have ver 1.02 :-( ) what about ARJ
  21. RJ>formats in the future maybe, as they are pretty popular
  22. RJ>too.
  23.  
  24. We've had a couple of requests for ARJ but, so far, no immediate plans
  25. on adding it to APRO.
  26.  
  27. RJ>Also a good Novell Netware library would be
  28. RJ>excellant.  Have been using the routines in Netware.Tpu &
  29. RJ>have written a chat program that allows two users to chat
  30. RJ>to each other over the network.  I would really like to see
  31. RJ>some more net utils in the future though.
  32.  
  33. What would you like to see that we don't already provide?
  34.  
  35. Note that one big difficulty in providing Netware utilities is
  36. documenting them. If we provide everything in the Netware API we
  37. essentially have to duplicate all of the Netware documentation (and then
  38. some). Our approach so far as been to provide and document the popular
  39. APIs, provide with minor documentation (as bonus units) the less
  40. popular APIs and ignore, for now, the more esoteric portions of the API.
  41.  
  42. RJ>Also, in the NSend & NReceive programs, I can't really see
  43. RJ>how the code establishes the "Two-Way" communications, as
  44. RJ>the manual seems to suggest that SPX is one way for one
  45. RJ>channel (socket?), without resorting to some tricky
  46. RJ>techniques.
  47.  
  48. I have to confess I'm not sure what special technique in NSEND/NRECEIVE
  49. the manual is referring to there; I've always used two sockets for
  50. two-way communication.
  51.  
  52. Looking at the code, my guess is there's not much to reversing the
  53. connection; just have the receiver call SpxSend and the transmitter call
  54. SpxListenPooled when you need to reverse the connection. What the manual
  55. was trying to bring out, I think, was the difficulty in providing
  56. general purpose routines to handle two-way communication.
  57.  
  58. Given that I'm not sure about this, you should probably call our tech
  59. support line (719-260-6641) for a definitive answer.
  60.  
  61. -Terry
  62.  
  63. ___
  64.  X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)
  65.  
  66. --- Maximus/2 2.01wb
  67.  * Origin: The Programmers Playhouse (1:128/60)
  68.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:46:53
  69.  
  70. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  71.  
  72. Conference 4
  73. Date       01-12-93 08:12:00
  74. From       Terry Hughes
  75. To         Rob Kittredge
  76. Subject    EXECWSWP question
  77.  
  78.  
  79. RK>Terry,
  80. RK>  I know that you document that you do not support EXECWSWP.  However,
  81. RK>I've got a quick question that may need just a simple answer.  I have
  82. RK>the new PKZip 2.04c.  One of my programs uses PKZip within a window
  83. RK>with EXECWSWP.  Do you know if PKZip now does direct screen writes?
  84. RK>Because it no longer stays neatly inside my EXECWSWP window.  Or is
  85. RK>there something I can do to EXECWSWP to make it work properly?
  86. RK>  One more question...Remember I called a while back about problems
  87. RK>with APro's Zmodem aborting when used w/large outbound buffers and you
  88. RK>fixed it by having me manually change the TransTimeout variable?  Did
  89. RK>you ever find a general purpose way to fix this?  And how's that SEAlink
  90. RK>code coming <g>?
  91. RK>  Thanks for your help!!
  92.  
  93. If it's writing outside the window then I'd have to guess it's doing
  94. direct screen writes now. If that's true there's not much you can do
  95. about it. To make sure you're not doing something wrong with EXECWSWP
  96. you might want to try some other programs to see if they stay within the
  97. window. You might also want to see if PKZIP 2.04c has some command line
  98. switch to control whether it writes through DOS or directly.
  99.  
  100. I recall the problem with Zmodem (sort of). At the time I had an answer
  101. and called the number you gave me but apparently you had gone back to
  102. school by then. I'm kind of foggy on the details now but I think the
  103. following entry from our change log provides a fix:
  104.  
  105. OOZMODEM fix  tzSendFinish state should be using FinishWait
  106. ___--------------------------------------------------------
  107. tzSendFinish state should be using FinishWait instead of HandshakeWait.
  108. Change as follows:
  109.  
  110.       tzSendFinish :
  111.         begin
  112.           ...
  113.           NewTimer(ReplyTimer, FinishWait);                  {!!.10}{!!.11}
  114.         end;
  115.  
  116. The above code used to reference TransTimeout when it should have been
  117. referencing FinishWait. That's why changing FinishWait didn't solve your
  118. problem but changing TransTimeout did.
  119.  
  120. -Terry
  121.  
  122. ___
  123.  X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)
  124.  
  125. --- Maximus/2 2.01wb
  126.  * Origin: The Programmers Playhouse (1:128/60)
  127.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:46:53
  128.  
  129. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  130.  
  131. Conference 4
  132. Date       01-12-93 08:12:00
  133. From       Terry Hughes
  134. To         Joe Jared
  135. Subject    comm ports
  136.  
  137.  
  138. JJ>In a message to Ron Allred <08 Jan 93 09:15> Kelly Small wrote:
  139.  
  140. JJ> >RA> Speaking of Comm Ports..  is there any Comm driver that will
  141. JJ> >RA> handle 115200 Baud?
  142.  
  143. JJ> KS> If you mean a Pascal driver, I doubt if you can make one that
  144. JJ> KS> will run that speed, especially if disk transfers are being used.
  145.  
  146. JJ>     If it has internal buffering, I don't see why not.
  147. JJ>Laplink works fine at 115kbaud. (I use it for Mac-IBM
  148. JJ>transfers).  A [2..8]k buffer should be sufficient for such
  149. JJ>a driver.
  150.  
  151. LapLink and similar products use what's usually called a semi-sync
  152. driver to obtain that speed. The ISR has receive interrupts enabled to
  153. receive the first character of a block, but then it turns off interrupts
  154. and starts polling for data in a very tight loop. Such an approach
  155. requires far fewer instructions to handle each received character then a
  156. general purpose interrupt handler but, obviously, requires this
  157. specialized driver at each end. This is how LapLink achieves 115Kbaud on
  158. slower machines that might not reach that speed with a more typical
  159. communications program (in throughput rather than actual baud rate).
  160.  
  161. -Terry
  162.  
  163. ___
  164.  X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)
  165.  
  166. --- Maximus/2 2.01wb
  167.  * Origin: The Programmers Playhouse (1:128/60)
  168.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:46:53
  169.  
  170. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  171.  
  172. Conference 4
  173. Date       01-12-93 19:58:00
  174. From       Trevor Carlsen
  175. To         Steve Mckain
  176. Subject    Array Of Char[1..31] of Char
  177.  
  178.  
  179.  
  180.  SM> I was wondering if it is possible to change the contents of
  181.  SM> a Type variable defined as a Array[1..31] of Char. When I
  182.  SM> read a record file for some reason the Array holds old
  183.  SM> charactors from the previous read and displays them with the
  184.  SM> new. Example
  185.  
  186.            Type
  187.             Users = Record
  188.               Names       : Array[1.31] of Char;
  189.  
  190.         While not EOF UserFile do begin
  191.          read(UserFile.Users)
  192.           With Users do begin
  193.          Writeln(textfile, Names);
  194.  
  195. Unless you know how many valid characters are in the array, I do not think
  196. this can be done.  If the array is a nul terminated string then there is no
  197. problem -
  198.  
  199.  function Asc2Str(var s; max: byte): string;
  200.    { Converts an ASCIIZ string to a Turbo Pascal string }
  201.    { with a maximum length of max.                      }
  202.    var starray  : array[1..255] of char absolute s;
  203.        len      : integer;
  204.    begin
  205.      len        := pos(#0,starray)-1;                       { Get the length }
  206.  
  207.      if (len > max) or (len < 0) then               { length exceeds maximum }
  208.  
  209.        len      := max;                                  { so set to maximum }
  210.  
  211.      Asc2Str    := starray;
  212.      Asc2Str[0] := chr(len);                                    { Set length }
  213.  
  214.    end;  { Asc2Str }
  215.  
  216.  
  217. TeeCee
  218.  
  219. --- TC-ED   v2.01  
  220.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  221.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:21
  222.  
  223. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  224.  
  225. Conference 4
  226. Date       01-12-93 20:10:00
  227. From       Trevor Carlsen
  228. To         Dave Speringo
  229. Subject    Clearing DOS MEMORY in RECORDS
  230.  
  231.  
  232.  
  233.  DS> ...The IDE compiler doesn't clear the dos memory buffers
  234.  DS> when it loads my program and runs it and when I read or
  235.  DS> write a record in a .dat file it sends whatever crap was in
  236.  DS> the buffer into some of the record file. Now, How do you
  237.  DS> clear the dos memory before the start of the program so as
  238.  DS> to ensure clean file writing and reading? Now I understand
  239.  DS> how to use FILLCHAR, but the problem lies in the dos buffer
  240.  DS> I believe.
  241.  
  242. The problem lies in incorrectly initialised records, not with the "dos buffer".
  243.  
  244. You are on the right track with FillChar.  Use it to initialise records before
  245. using them.  If a record read from disk already has garbage then it would
  246. be difficult to eliminate that garbage.
  247.  
  248. TeeCee
  249.  
  250.  
  251. --- TC-ED   v2.01  
  252.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  253.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:21
  254.  
  255. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  256.  
  257. Conference 4
  258. Date       01-12-93 20:13:00
  259. From       Trevor Carlsen
  260. To         Karim Sultan
  261. Subject    Even Faster Way...
  262.  
  263.  
  264.  
  265.  KS> Heres an even faster method that doesn't need the Dos unit:
  266.  
  267.  KS> Var
  268.  KS>    MyFile     : File;
  269.  KS>    FileExists : Boolean;
  270.  KS> Begin
  271.  KS>    Assign (MyFile, 'MyFile.Ext');
  272.  KS>    {$I-}
  273.  KS>    Reset  (MyFile);
  274.  KS>    {$I+}
  275.  KS>    FileExists := (IOResult<>0);
  276.  KS> End.
  277.  
  278. It might be faster (I doubt it though) but may not work and has other disadvanta
  279. es.  One is that it will return a false value if the file is Read Only unless
  280. you set the FileMode variable appropriately, another is that it uses a file
  281. handle and leaves a found file open.
  282.  
  283. TeeCee
  284.  
  285. --- TC-ED   v2.01  
  286.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  287.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:21
  288.  
  289. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  290.  
  291. Conference 4
  292. Date       01-13-93 04:24:00
  293. From       Trevor Carlsen
  294. To         Jeff Jernegan
  295. Subject    Reading fixed length ASCII records
  296.  
  297.  
  298.  
  299.  JJ> I'm dealing with a 87,000 record data file composed of
  300.  JJ> fixed-length ASCII fields totalling 197 characters per line
  301.  JJ> (one record per line). I defined a record of various strings
  302.  JJ> totalling 197 characters, then a file of those records.
  303.  JJ> There are no separations or delimiters between the ASCII
  304.  JJ> characters in one string and the next. After Assigning,
  305.  JJ> Resetting, Seeking a record and Reading it, I tried to write
  306.  JJ> the various strings composing the record to screen. Got
  307.  JJ> output that leads me to believe the strings composing the
  308.  JJ> record are not being truncated at their defined lengths (ie
  309.  JJ> name : string[30] displays MORE than 30 characters when I
  310.  JJ> write it.) What am I doing wrong?
  311.  
  312.  JJ> PROGRAM RECORDS;
  313.  JJ> uses crt;
  314.  JJ> const
  315.  JJ>    FileName = 'd:\license\cl1-6-93.dat';
  316.  JJ> type
  317.  JJ>    contractor =
  318.  JJ>         record
  319.  JJ>            Number : string[12];
  320.  JJ>            ctype  : string[2];
  321.  JJ>            name   : string[30];
  322.  JJ>            other  : string[153];
  323.  JJ>         end;
  324.  JJ> 
  325.  JJ> var
  326.  JJ>    i      :    integer;
  327.  JJ>    onerec :    contractor;
  328.  JJ>    f      :    file of contractor;
  329.  JJ> Begin
  330.  JJ>    ClrScr;
  331.  JJ>    Assign(f,filename);
  332.  JJ>    Reset(f);
  333.  JJ>    For i := 0 to 4 do
  334.  JJ>    Begin
  335.  JJ>       Seek(f,i);
  336.  JJ>       Read(f,onerec);
  337.  JJ>       With onerec do Writeln('Record#: ',i,'  Lic.#: ',number,
  338.  JJ>               '  Name: ',name);
  339.  JJ>    End;
  340.  JJ>    Close(f);
  341.  JJ> End.
  342.  
  343. sizeof(contractor) is equal to 201 bytes because of the length bytes for the
  344. four string fields.
  345.  
  346. How was the file originally written?  The fact that onerec.name displays more
  347. than 30 characters would indicate that the length byte is > 30.  If you are
  348. using a program written in TP to write the record to disk then this can happen
  349. in various ways. 
  350.  
  351. The first suspect I would look at is strict string variable type checking
  352. is turned off.  eg.
  353.  
  354.   procedure GetName(var n: string);
  355.     begin
  356.       write('Enter name: ');
  357.       readln(n);
  358.     end;
  359.  
  360.   with onerec do
  361.     GetName(name);
  362.  
  363. If strict type checking is off and a name of > 30 characters is entered that
  364. would produce the effect you are seeing.  There are other ways but I would
  365. advise that first turn strict checking on (  {$V+}   ) and try it.
  366.  
  367. TeeCee
  368.  
  369. --- TC-ED   v2.01  
  370.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  371.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:21
  372.  
  373. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  374.  
  375. Conference 4
  376. Date       01-13-93 04:38:00
  377. From       Trevor Carlsen
  378. To         Will Fong
  379. Subject    Re: WRITELN IN TWO OR MOR
  380.  
  381.  
  382.  
  383.  JL> Hey. I'll give you some advice before some of the meaner
  384.  JL> guys do!! I'm new to Pascal also.  For most questions you
  385.  JL> better try the Pascal Lessons echo.  There are some good
  386.  JL> programmers like Mike Copeland that will help you over
  387.  JL> there. They don't like simple questions over here. TRUST
  388.  JL> ME!! Talk to ya over there. Later...
  389.  
  390.  WF> From what I know, there is not Pascal Lesson echo on this
  391.  WF> board or on anyone else that I'm on.
  392.  
  393.  JL> BTW, the BLOCKADE BBS (number below) has two good TP tutors
  394.  JL> that I uploaded there. If you can't find them elsewhere try
  395.  JL> there. C-YA.
  396.  
  397.  WF> ...I'll take my chances here because on the board I'm on,
  398.  WF> this is the most logical area to post it in, so it's not my
  399.  WF> fault, that is, unless the moderator says otherwise.
  400.  
  401. I believe that there is a Pascal Lessons echo in zone 1.  However this echo
  402. is most definitely applicable to all skill levels in the language and you
  403. are more than welcome to post simple (or complex) questions here.
  404.  
  405. However, we do expect that you understand enough enough about programming
  406. fundamentals to be able to understand fundamental answers.  Eg. "What does
  407. a variable type mean?" would indicate that you are unaware of even the most
  408. basic principles of programming and this would make it very hard to help you.  
  409.  
  410. The person giving you the advice to go elsewhere was recently asking questions
  411. of almost that level and whilst I would never ask him to go elsewhere, I would
  412. not answer such a question here as I believe it indicates that no attempt
  413. has been made to do any learning at all before the request.  
  414.  
  415. My own approach to answering questions is based on helping almost everyone.
  416. "Almost" because I never answer questions directly where the answer is easily
  417. available just by looking it up in the manual or where the question itself
  418. indicates that the asker does not own a legitimate copy of the compiler. 
  419. Other than those caveats, I will attempt to help whenever I can.
  420.  
  421.  
  422. Moderator.
  423. Moderator.
  424.  
  425. --- TC-ED   v2.01  
  426.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  427.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:22
  428.  
  429. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  430.  
  431. Conference 4
  432. Date       01-13-93 04:55:00
  433. From       Trevor Carlsen
  434. To         Francois Thunus
  435. Subject    TCSEL003: ReadTxt
  436.  
  437.  
  438.  
  439.  FT>> ... when i try to read a text with more than 254
  440.  FT>> lines, it freezes even thought i still have more than 500k
  441.  FT>> available
  442.  
  443.  TC> Have you changed the type of NumberLines?
  444.  
  445.  FT> no.
  446.  
  447. Ok...then the problem would appear to be not in the code you posted.  As my
  448. example does not suffer the same problem, it must be something in your code
  449. causing the problem.  If you netmail me your code I will take a look at it.
  450.  
  451. TeeCee
  452.  
  453. --- TC-ED   v2.01  
  454.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  455.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:22
  456.  
  457. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  458.  
  459. Conference 4
  460. Date       01-13-93 04:58:00
  461. From       Trevor Carlsen
  462. To         Matt Blanshard
  463. Subject    HELP!
  464.  
  465.  
  466.  
  467.  MB> ...when I put in a readln statement it just skips over it.
  468.  
  469. Can you give us a short example that demonstrates the problem?
  470.  
  471. However one point  you must remember is - 
  472.  
  473. if you have disabled I/O checking and at some point have had an I/O error
  474. of any kind then no further I/O can occur until the IOResult function is called.
  475. The following code demonstrates the "problem" -
  476.  
  477.   var
  478.     st : string;
  479.     f  : file;
  480.   begin
  481.     {$I-}
  482.     close(f);  { error would occur here but not crash due to I- }
  483.     writeln('This will not display');
  484.     if IOResult = 0 then;  { just a dummy call for demo purposes }
  485.     writeln('But this will display');
  486.   end.
  487.  
  488. This behaviour is clearly described in the manual on page 134 of the BP7Programm
  489. r's Reference. I don't know if the TP7 manual is similar but it is in the
  490. IOResult function description.
  491.  
  492. TeeCee
  493.  
  494. --- TC-ED   v2.01  
  495.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  496.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:22
  497.  
  498. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  499.  
  500. Conference 4
  501. Date       01-13-93 05:16:00
  502. From       Trevor Carlsen
  503. To         Carlos Beguigne
  504. Subject    RRRQuestion
  505.  
  506.  
  507.  
  508.  CB> ...I work for a bank and would like to create a program to
  509.  CB> maintain better record of our Cashier Checks and also any
  510.  CB> stop payments on them..I have done very little programming
  511.  CB> on pascal. Ok here goes:
  512.  CB>         I would like to make the input of numbers to move
  513.  CB>         from a fixed point to the left and insert commas
  514.  CB>         every three digits for monetary figures?
  515.  
  516. You will need to set up a dedicated character by character input routine using
  517. ReadKey and controlling the display yourself.  After each character is entered
  518. examine it and determine whether or not to add a comma.  The following very
  519. simple (and untested) routine demonstrates this.  
  520.  
  521. For a better way to do such input find and download TCSEL003.* from a PDN
  522. node near you and study the KEYINPUT unit.  You may be able to modify it to
  523. do exactly what you want or perhaps use it as a guide to producing your own
  524. "bullet proof" input routine. 
  525.  
  526. function LastPos(ch : char; S : string): byte;
  527.   { Returns the last position of ch in S or zero if ch not in S }
  528.   var
  529.     x   : word;
  530.     len : byte absolute S;
  531.   begin
  532.     x := succ(len);
  533.     repeat
  534.       dec(x);
  535.     until (x = 0) or (S[x] = ch);
  536.     LastPos := x;
  537.   end;  { LastPos }
  538.  
  539.  
  540. procedure GetNumber(fieldwidth: byte);
  541.   var ch : char;
  542.       x,y: byte;
  543.       i  : word;
  544.   begin
  545.     st := '';
  546.     write('Enter a number: ');
  547.     x := WhereX;
  548.     y := WhereY;
  549.     repeat
  550.       ch := ReadKey;
  551.       case ch of 
  552.         '0'..'9': begin
  553.                     if LastPos(',',st) = length(st)-3 then
  554.                       st := st + ',';
  555.                     st := st + ch;
  556.                   end;
  557.         #8      : begin
  558.                     delete(st,length(st),1);
  559.                     if st[length(st)] = ',' then
  560.                       delete(st,length(st),1);
  561.                   end;
  562.         #13     : exit;
  563.       end;
  564.       gotoXY(x,y);
  565.       write(st:fieldwidth);
  566.     until false;  
  567.   end;
  568.  
  569. TeeCee
  570.       
  571.  
  572. --- TC-ED   v2.01  
  573.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  574.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:22
  575.  
  576. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  577.  
  578. Conference 4
  579. Date       01-12-93 08:11:00
  580. From       Dj Murdoch
  581. To         Dennis Alexander
  582. Subject    Re: Turbo Vision Echo
  583.  
  584.   DA>         Is the Turbo Vision echo available on the 
  585.  DA> backbone, and if so, what
  586.  DA> is the tag name?  Sorry if this is off-topic, but I didn't know where else
  587.  
  588.  DA> to post it.  Thanks!
  589.  
  590. It's not off-topic, nor are questions about TV.  
  591.  
  592. Here's a quote of a message from Mike Janke to tell you where to get it:
  593.  
  594.  Area name is TURBOVISION
  595.  
  596. It is not on the backbone... yet.  It can be had from 208/1 (or Pam can advise
  597. you if there is a better location) or you can get it from me.
  598.  
  599.  Origin: Kendall BBS - Miami, Florida (305)271-2146 (1:135/4)
  600.  
  601.  
  602. --- Msg V3.2
  603.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  604.  * Tossed by SFToss/286 v1.02a on 93/01/14  08:47:22
  605.  
  606. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  607.  
  608. Conference 4
  609. Date       01-13-93 08:13:00
  610. From       Dj Murdoch
  611. To         Jud Mccranie
  612. Subject    Re: TP 7.0
  613.  
  614.   JM> The Search and
  615.  JM> F&R in 6.0 and 7.0 is still about the worst thing I've ever seen
  616.  JM> on a computer.  (Offhand I can't think of anything designed that
  617.  JM> poorly.  They didn't do a single thing to fix it in 7.0, so I'd expect
  618.  JM> a major overhaul of it in the next release in a year or 2.
  619.  
  620. Sure they fixed it - look at the new options in the Preferences menu.  You
  621. can now default to the previous search string, instead of the current token.  
  622.  
  623.  
  624.  
  625. --- Msg V3.2
  626.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  627.  * Tossed by SFToss/286 v1.02a on 93/01/14  11:28:48
  628.  
  629. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  630.  
  631. Conference 4
  632. Date       01-13-93 08:15:00
  633. From       Dj Murdoch
  634. To         jonny bergdahl
  635. Subject    Re: BP 7 bug list
  636.  
  637.   > 29. On a 386, a longint shift of 16 bits or more is unreliable. (A fix
  638.  > is available in NEWSHR.FIX.)
  639.  
  640.  JB> Where do I find those .FIX files?
  641.  
  642. Look for BP7BUGS1.ZIP on any PDN Pascal node near you.  It's also available
  643. on Internet by anonymous ftp from garbo.uwasa.fi:/pc/turbopas, and on Compuserve
  644. in CLMFORUM DL 16.  If none of those are possibilities for you, I'll mail
  645. it to you on a 5 1/4" diskette, but I'll charge $10 (Canadian or US) for that
  646. service.  Send payment to me at 
  647.  
  648.    337 Willingdon Ave.
  649.    Kingston, Ontario, Canada
  650.    K7L 4J3
  651.  
  652. --- Msg V3.2
  653.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  654.  * Tossed by SFToss/286 v1.02a on 93/01/14  11:28:48
  655.  
  656. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  657.  
  658. Conference 4
  659. Date       01-13-93 08:22:00
  660. From       Dj Murdoch
  661. To         Calvin Cook
  662. Subject    Re: Upgrade
  663.  
  664.   CC> Well TP7.0 is here and borland didn't send me a notice of 
  665.  CC> that fact or any special price notices either. So what do 
  666.  CC> I have to do to receive an upgrade at on an upgrade price?
  667.  
  668. Just call them up (their number is 1-800-331-0877 ext 5016 from the USA, 1-800-4
  669. 1-3327 from Canada, they don't seem to advertise a number for the rest). 
  670. As long as you have a serial number, they'll take your money.
  671.  
  672.  CC> Jump cut again:  back to the TURBO VISION experts. If any 
  673.  CC> of you could provide the code to make the 'hello, world' 
  674.  CC> popup window ('HOW ARE YOU?' buttons: 'TERRIFIC, OK, 
  675.  CC> LOUSY, CANCEL' look like a WINDOW it would be greatly appreciated
  676.  
  677. I don't know any of the example programs you mentioned.  What do you mean
  678. by "look like a WINDOW"?
  679.  
  680. --- Msg V3.2
  681.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  682.  * Tossed by SFToss/286 v1.02a on 93/01/14  11:28:49
  683.  
  684. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  685.  
  686. Conference 4
  687. Date       01-13-93 08:27:00
  688. From       Dj Murdoch
  689. To         Gordon Tackett
  690. Subject    Re: 300% barrier broken
  691.  
  692.   >>>         LHarc 1.13c (By Haruyasu YOSHIZAKI )
  693.  >>>         The original designer of huffman compression.
  694.  >  GT> Gee and I thought it was called huffman encoding because Huffman
  695.  >  GT> designed it around 1975.
  696.  
  697.  > You're absolutely correct.  I've been researching the
  698.  > developement history  of compression algorythms, and
  699.  > will be removing that line from the documentation.
  700.  > Actually, the first documented date of huffman
  701.  > compression I've seen is 1977, so if you have a
  702.  
  703.  GT> I stand corrected. but I did say around 1975 :-) My refs ar also for 1977.
  704.  
  705.  
  706. You were closer.  Huffman published his algorithm in 1952.  What refs are
  707. you looking in?!?  
  708.  
  709. --- Msg V3.2
  710.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  711.  * Tossed by SFToss/286 v1.02a on 93/01/14  11:28:49
  712.  
  713. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  714.  
  715. Conference 4
  716. Date       01-13-93 08:38:00
  717. From       Dj Murdoch
  718. To         Martin Austermeier
  719. Subject    Re: DPMI and debugging
  720.  
  721.   MA> Do we have to live with the fact that the integrated 
  722.  MA> debugger doesn't work in DPMI mode?
  723.  
  724.  MA> I haven't found that documented yet, so it is a bug, isn't it?
  725.  
  726. I don't know if it's documented or not, but it's a well-known problem---use
  727. TDX instead.  Borland seems to be unable to produce an integrated debugger
  728. in protected mode.  You have the same problem under windows, where you have
  729. to use TDW. 
  730.  
  731. --- Msg V3.2
  732.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  733.  * Tossed by SFToss/286 v1.02a on 93/01/14  11:28:49
  734.  
  735. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  736.  
  737. Conference 4
  738. Date       01-13-93 08:41:00
  739. From       Dj Murdoch
  740. To         Richard Nelson
  741. Subject    Re: Modifying the interiors of a specifi
  742.  
  743.   PD> I would like to be able to use a procedure/method 
  744.  PD> that would modify the
  745.  PD> interior of the specified interior by writing to the bottom of that
  746.  PD> window, for instance:
  747.  
  748.  RN> TTerminal does exactly what you're looking for.
  749.  
  750. But it does it even better if you make it fixed width, instead of recalculating
  751. the width after every write...
  752.  
  753. --- Msg V3.2
  754.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  755.  * Tossed by SFToss/286 v1.02a on 93/01/14  11:28:49
  756.  
  757. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  758.  
  759. Conference 4
  760. Date       01-13-93 20:08:00
  761. From       Dj Murdoch
  762. To         Peter Brunet
  763. Subject    Re: Break & continue
  764.  
  765.   PB> Ok..  Here's some BASIC code that we had to convert to 
  766.  PB> Pascal for school..  The Pascal code came out much longer. 
  767.  PB>  I'd enjoy seeing it done better than I did..
  768.  
  769.  PB> 90 for z = 2 to n^2
  770.  PB> 100   if z-1 <= 0 then 130
  771.  PB> 110   i = i - 1
  772.  PB> 120   goto 140
  773.  PB> 130   i = n
  774.  PB> 140   if j+1 > n then 170
  775.  PB> 150   j = j + 1
  776.  PB> 160   goto 180
  777.  PB> 170   j = 1
  778.  PB> 180   c = c + 1
  779.  PB> 190   a(i,j) = z
  780.  PB> 200   if c/n <> int(c/n) then 230
  781.  PB> 210   i = i + 2
  782.  PB> 220   j = j - 1
  783.  PB> 230 next z
  784.  
  785. All of those goto's (including the implicit ones in the IF statements) are
  786. just a slightly confusing way to code "if ... then ... else ... ".  I didn't
  787. get your Pascal version, but I can't imagine what you would have done to make
  788. it harder to read.
  789.  
  790. Oops, just came across your Pascal version.  I don't know why you bothered
  791. setting up all those procedures and functions - the BASIC code seems a more
  792. natural way to implement the loop, especially if you use the suggestion above.
  793.  You didn't need to bother with the Power function, since TP supplies sqr(),
  794. and that's all you needed here. 
  795.  
  796. --- Msg V3.2
  797.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  798.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:22
  799.  
  800. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  801.  
  802. Conference 4
  803. Date       01-11-93 23:17:00
  804. From       Mark Ouellet
  805. To         Grischa Brockhaus
  806. Subject    Re: Exec Within A Window! 1/3
  807.  
  808.  
  809.     On 04-Jan-93, you, Grischa Brockhaus, of 2:2403/45.22 wrote...
  810.  
  811.  GB> Ahem... I have to say first: My aktual XExec Unit changed a lot, it 
  812.  GB> *don't needs* the XCrt-Unit...
  813.  GB> 
  814.  GB> I really can't remember, why I used XCrt in this unit, only *perhaps* 
  815.  
  816.  GB> because of 2 Procedures, here they are:
  817.  
  818.  GB> I hope this will help. If not, try to compile the unit w/o the "uses 
  819.  
  820.  GB> XCrt" and tell me, wich procedures you need, ok ?
  821.  
  822. Thanks Grischa,
  823.     I will, unless I can determine what they do and build my own. I
  824. mainly sent the question because someone else had mentionned the unit
  825. missing from the post. I must admit I hadn't tried it yet and assumed
  826. there might be more routines than what you gave me.
  827.  
  828.         Best regards,
  829.         Mark Ouellet.
  830.  
  831.  
  832. --- QM v1.30 
  833.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  834.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:22
  835.  
  836. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  837.  
  838. Conference 4
  839. Date       01-11-93 23:20:00
  840. From       Mark Ouellet
  841. To         John Martzall
  842. Subject    Re: password
  843.  
  844.  
  845.     On 06-Jan-93, you, John Martzall, of 1:129/163.0 wrote...
  846.  
  847.  -=>> Quoting Mark Ouellet to John Martzall <=-
  848.  
  849.  JM> So whut you are saying is that you have passwords in the program
  850.  JM> that are unchangable?
  851.  
  852.     Yes, they are defined as typed constants so their position in the
  853. .exe can be calculated.
  854.  
  855.  JM> If not, how are they changed in the direct exe file?
  856.  
  857.     By calculating their position in the Exe and updating the EXE from
  858. that offset for ITEM_SIZE bytes long.
  859.  
  860.  JM> Also, if the passwords are in the exe, why do they need encrypted?
  861.  
  862. Because otherwise, a simple look at the EXe would reveal the passwords
  863. unless I used something like PKlite that compresses the EXE, rendering
  864. the paswords unreadable to prying eyes.
  865.  
  866.  JM> And from whut do you derive the key for encryption?
  867.  
  868.     At the moment it is a Longint generated from the Random routine and
  869. passed through another function that adds an additionnal difficulty. The
  870. additionnal function could be anything, a hash from the users name, my
  871. Social Security Number etc... Anything specific so that simple
  872. comparison with the Random sequence is not sufficient to determine the
  873. password when trying to decypher them.
  874.  
  875.  JM> and how does the program remember the new encryption key each time?
  876.  
  877.     It too is stored as an typed constant, and it too is reqritten to
  878. the exe on each run.
  879.  
  880.  JM> You have brought up many interesting questions.
  881.  
  882. Hope you find the answers as interesting John ;-)
  883.  
  884.         Best regards,
  885.         Mark Ouellet.
  886.  
  887. BTW, I allready sent the PatchEXE routine on this echo a few days ago.
  888.  
  889.  
  890. --- QM v1.30 
  891.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  892.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:22
  893.  
  894. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  895.  
  896. Conference 4
  897. Date       01-11-93 23:26:00
  898. From       Mark Ouellet
  899. To         Dj Murdoch
  900. Subject    Re: Turbo Vision
  901.  
  902.  
  903.     On 07-Jan-93, you, Dj Murdoch, of 1:249/99.5 wrote...
  904.  
  905.  MO>> the TurboVision echo is the best place for that.
  906.  
  907.  DM> It's not on the backbone yet; how does someone get hold of it?
  908.  
  909. Dj,
  910.     With TeeCee's permission I'll ask Jim Barchuck to send a List of
  911. nodes where either someone can pick it up or where a Willing sysop can
  912. link up to receive it.
  913.  
  914.     BTW some of those nodes accept points also. That is how I was first
  915. to receive it until my Boss/node got news of it and proposed to get it
  916. himself and add it to his list of available echoes.
  917.  
  918.         Best regards,
  919.         Mark Ouellet.
  920.  
  921.  
  922. --- QM v1.30 
  923.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  924.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:22
  925.  
  926. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  927.  
  928. Conference 4
  929. Date       01-11-93 23:30:00
  930. From       Mark Ouellet
  931. To         Dj Murdoch
  932. Subject    Re: Troi
  933.  
  934.  
  935.     On 07-Jan-93, you, Dj Murdoch, of 1:249/99.5 wrote...
  936.  
  937.  DM> I won't be taking over until Feb 1, and only then if TC doesn't change 
  938.  
  939.  DM> his mind.  There isn't any "normal term" or provision for an election 
  940.  
  941.  DM> for the position unless the moderator calls one (or disappears and 
  942.  DM> someone else calls one).  
  943.  DM> 
  944.  DM> This is in the rules that TC posts monthly.  I'm not planning any 
  945.  DM> changes.  The moderator is a constitutional monarch, not a president 
  946.  
  947.  DM> :-).
  948.  
  949. Of course Dj,
  950.     I simply thought you might want to schedule elections after some
  951. time since you were nominated by TeeCee. This echo is of course a
  952. special case where the moderatorship is not of predefined time. As such
  953. I thought you might like to declare elections some time in the near
  954. future to confirm your appointement.
  955.  
  956.     Seeing the lack of opposition to your succession to TeeCee I guess
  957. the elections won't be usefull after all.
  958.  
  959.     I sure would prefer to keep you until you've had enough of us ;-)
  960. and forget the whole elections deal!!
  961.  
  962.         Best regards,
  963.         Mark Ouellet.
  964.  
  965.  
  966. --- QM v1.30 
  967.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  968.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:23
  969.  
  970. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  971.  
  972. Conference 4
  973. Date       01-11-93 23:35:00
  974. From       Mark Ouellet
  975. To         Kaido Karner
  976. Subject    Re: Protected Mode IDE problems
  977.  
  978.  
  979.     On 03-Jan-93, you, Kaido Karner, of 2:490/43.0 wrote...
  980.  
  981. KK> As I understand, You are talking about the problem in BP protected
  982. KK> mode with keyboard, ie some nasty numbers from array keys, missing
  983. KK> shifts etc .. I got this problem about year ago in an text editor.
  984. KK> And I think, the problem is that using some protected mode soft
  985. KK> (like Borland DPMI server or QEMM) there may occure next problem:
  986. KK> each time when a keyboard controller generates interrupt, the
  987. KK> protected mode server must disable A20 and turn to standard mode to
  988. KK> serve the interrupt. And then it turnes beck to protected mode. And
  989. KK> there is possibility that some interrupts from keyboard may be lost.
  990. KK> I solved this problem stopping loading DOS high this time. But there
  991. KK> are of course other solutions depending what really is the problem
  992.  
  993. Kaido,
  994.     As someone else pointed out the problem is often that these
  995. applications have a way of pointing out flaky hardware. I know the same
  996. setup that caused a 386 to behave this way was bugsless on other makes
  997. and models.
  998.  
  999.         Best regards,
  1000.         Mark Ouellet.
  1001.  
  1002.  
  1003. --- QM v1.30 
  1004.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1005.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:23
  1006.  
  1007. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1008.  
  1009. Conference 4
  1010. Date       01-11-93 23:57:00
  1011. From       Mark Ouellet
  1012. To         Robert Jambor
  1013. Subject    Re: ..
  1014.  
  1015.  
  1016.     On 30-Dec-92, you, Robert Jambor, of 3:640/521.64 wrote...
  1017.  
  1018.  RJ> Isn't a BBS considered worthy of Pascal <g>  Why is everyone so against 
  1019.  
  1020.  RJ> the writing of BBS code.  So far, I have yet to see a decent BBS program 
  1021.  
  1022.  RJ> commercial or otherwise, so why not build a better mousetrap.  Does it 
  1023.  
  1024.  RJ> really mater *what* a person writes in Pascal; I think not.
  1025.  
  1026. Well Robert,
  1027.     would you rather give your 4 years old a Kawasaki 1000 or a small
  1028. bike with training weels???
  1029.  
  1030.     That is why Mike, like me and others, can't understand why a
  1031. beginner would want to try and write a BBS.
  1032.  
  1033.     Most of these beginers don't even have enough understanding of the
  1034. machine, let alone the language, to write such a thing. They often think
  1035. that they can open COM1 as a file and expect it to support 19200 bps!!
  1036.  
  1037.     You don't ask three year olds to paint a Monalisa!!! There are
  1038. enough projects that will help them learn the language as it is. And
  1039. frankly we don't need another half backed BBS. There are plenty of those
  1040. around.
  1041.  
  1042.     And frankly, what is probably most disturbing is that this echo's
  1043. participants are writing that BBS, not the beginner since the echo
  1044. participant end up providing 50% of the real heavy code needed. In the
  1045. end, the beginner hasn't learned Pascal, he's learn communications and
  1046. will continue to need help with the langauage itself.
  1047.  
  1048.         Best regards,
  1049.         Mark Ouellet.
  1050.  
  1051.  
  1052. --- QM v1.30 
  1053.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1054.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1055.  
  1056. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1057.  
  1058. Conference 4
  1059. Date       01-12-93 00:09:00
  1060. From       Mark Ouellet
  1061. To         Greg Williams
  1062. Subject    Re: PROTOGEN for TP7.0
  1063.  
  1064.  
  1065.     On 05-Jan-93, you, Greg Williams, of 3:690/601.0 wrote...
  1066.  
  1067.  GW> Secondly, ProtoGen enforces its own 'style' on the code it
  1068.  GW> generates (which is fair 'nuf I guess), due to the placement of its 
  1069.  GW> 'REGEN' comment brackets.  These are a feature which allow the 
  1070.  GW> programmer to add his own code to that generated by ProtoGen, and have 
  1071.  
  1072.  GW> it preserved through future changes and code generation by ProtoGen...  
  1073.  
  1074.  GW> Unfortunately, nine times out of ten you'd like to add code in a place 
  1075.  
  1076.  GW> where there are NO regen brackets, or you'd like to change some of the 
  1077.  
  1078.  GW> 'ProtoGen-generated' code (like the initialisation part, to make the 
  1079.  
  1080.  GW> application start off in iconic form, etc).  In these cases, you either 
  1081.  
  1082.  GW> have to manually make your changes each time you regenerate the code, or 
  1083.  
  1084.  GW> have some sort of filecompare/script-editor to bring each new version of 
  1085.  
  1086.  GW> your code 'up-to-date' automatically.
  1087.  
  1088. Greg,
  1089.     Can't you add REGEN brackets yourself??? I thought you could, they
  1090. must be like compiler directives and allowed anywhere, aren't they???
  1091.  
  1092.         Best regards,
  1093.         Mark Ouellet.
  1094.  
  1095.  
  1096. --- QM v1.30 
  1097.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1098.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1099.  
  1100. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1101.  
  1102. Conference 4
  1103. Date       01-12-93 00:17:00
  1104. From       Mark Ouellet
  1105. To         Joe Konecny
  1106. Subject    Re: ANSI
  1107.  
  1108.  
  1109.     On 04-Jan-93, you, Joe Konecny, of 1:234/26.0 wrote...
  1110.  
  1111.  JK> Using TP 6.0
  1112.  JK> 
  1113.  JK> Can anyone tell me why this works -
  1114.  JK> PROGRAM AnsiTest;
  1115.  JK> BEGIN
  1116.  JK> WRITELN(#27'[35;1;5mTest');
  1117.  JK> And this doesn't -
  1118.  JK> PROGRAM AnsiTest;
  1119.  JK> Uses CRT;
  1120.  JK> BEGIN
  1121.  JK> WRITELN(#27'[35;1;5mTest');
  1122.  
  1123. TP 6.0,  Programmer's Guide, Chapter 15, Page 199!!!!
  1124.  
  1125.         Best regards,
  1126.         Mark Ouellet.
  1127.  
  1128.  
  1129. --- QM v1.30 
  1130.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1131.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1132.  
  1133. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1134.  
  1135. Conference 4
  1136. Date       01-12-93 00:24:00
  1137. From       Mark Ouellet
  1138. To         Doug Cox
  1139. Subject    Re: DELETING RECORDS IN FILES
  1140.  
  1141.  
  1142.     On 07-Jan-93, you, Doug Cox, of 1:106/7851.0 wrote...
  1143.  
  1144.  DC> Could someone please give me an example of a good way (the best way?) to 
  1145.  
  1146.  DC> delete records from a typed file?  My only guess, after looking at all 
  1147.  
  1148.  DC> of the TP documentation, and my one TP book, is that I will have to read 
  1149.  
  1150.  DC> the file, and write a new file, excluding the "deleted" record.  This 
  1151.  
  1152.  DC> will require another (identical) TYPE statment, and file variable, etc., 
  1153.  
  1154.  DC> and will require me to then rename the smaller file... 
  1155.  DC> 
  1156.  DC> Isn't there a more efficient way????
  1157.  
  1158. YES THERE IS!!!
  1159.  
  1160.  DC> Is it just me, or is this subject horribly missing from all of the TP 
  1161.  
  1162.  DC> books?!?!?! 
  1163.  
  1164. Doug,
  1165.     The main reason it is missing from TP books is that it is more
  1166. Datamanagement related than TP related. Most of those books deal with
  1167. the same basic problems over and over. They all overlap on most aspects.
  1168.  
  1169. Ok for that management problem:
  1170.  
  1171. Modify your record to this:
  1172.  
  1173. type
  1174.     My_Record = Record
  1175.         Deleted : boolean;
  1176.         < Rest of your usual stuff >
  1177.     end;
  1178.  
  1179.     Now if you use index files, create an index file with the DELETED
  1180. field as the key to that index.
  1181.  
  1182. Pseudo code ahead:
  1183.  
  1184.     Adding a record:
  1185.         1- Set index to DELETED
  1186.         2- Go to first record
  1187.         3- Is it deleted
  1188.         4- Yes, use it as our new record
  1189.             4a Change the Deleted field to False;
  1190.             4b Write our new record to this one overwriting it.
  1191.         5- No, Add a new phisical record to the file,
  1192.             5a Remember to Set Deleted to false on this one
  1193.             5b write our record to the new record.
  1194.  
  1195.     Deleting a Record:
  1196.         1- Go to Record,
  1197.         2- Read it in
  1198.         3- Set the deleted field to TRUE.
  1199.             { This allows UnDeleting a record with it's original data}
  1200.  
  1201.     Listing records:
  1202.         Remember to skip deleted records.
  1203.  
  1204. you will soon find that using this management method your applications
  1205. will perform at speeds vastly faster than others. Simply because the
  1206. file is never moved, truncated etc.. Eliminating fragentation on the
  1207. disk. You will also find that as you open new databases, they will
  1208. quickly grow and then attain a stable size where new records are mostly
  1209. reusing deleted records.
  1210.  
  1211.     This is how my dBase applications are handled. Our last project
  1212. while I was at the Justice Departement was re-written to use this
  1213. principle of management instead of using dBase's Pack and delete
  1214. routines. The efficiency was greatly augmented both in speed and in disk
  1215. occupation. We no longer needed to perform unfragmentation routines
  1216. periodically and we also could reverse any error our users might have
  1217. commited.
  1218.  
  1219.     By adding additionnal info such as deletion date, user ID that
  1220. requested the delete etc... we were able to offer options that were not
  1221. available before. An added benefit was that we didn't need to reindex
  1222. the whole database. Affected Index files were open during operations and
  1223. were thus opdated on the fly. So our Deleted index was allways uptodate.
  1224. Generating a message when physical space was added to the database, we
  1225. were able to perform defragementation only when really needed. And those
  1226. operations were greatly shortened in time because 98% of the database
  1227. was allready defragmentated.
  1228.  
  1229. It's the sensible way to do it, and it can be done in any language.
  1230.                             
  1231.         Best regards,
  1232.         Mark Ouellet.
  1233.  
  1234.  
  1235. --- QM v1.30 
  1236.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1237.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1238.  
  1239. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1240.  
  1241. Conference 4
  1242. Date       01-12-93 00:59:00
  1243. From       Mark Ouellet
  1244. To         Ronald Westphal
  1245. Subject    Re: Tvision echo
  1246.  
  1247.  
  1248.     On 08-Jan-93, you, Ronald Westphal, of 1:3811/25.0 wrote...
  1249.  
  1250.  RW> Is there an echo on or off the backbone for TVision?  If so can someone 
  1251.  
  1252.  RW> please post the area tag for it.
  1253.  
  1254. Ronald,
  1255.     the TAG is TURBOVISION but it's not on the backbone yet. I'll ask
  1256. Jim Barchuck to post a list of nodes here where someone can hookup to
  1257. it.
  1258.  
  1259.         Best regards,
  1260.         Mark Ouellet.
  1261.  
  1262.  
  1263. --- QM v1.30 
  1264.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1265.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1266.  
  1267. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1268.  
  1269. Conference 4
  1270. Date       01-12-93 03:29:00
  1271. From       Mark Ouellet
  1272. To         Michel Dussault
  1273. Subject    Re: Bp 7.0 Utilities (bo
  1274.  
  1275.  
  1276.     On 09-Jan-93, you, Michel Dussault, of 1:240/518.0 wrote...
  1277.  
  1278.  MD> Yon must try "A l'enseigne du livre" on Pierre-Bertrand! I found 
  1279.  MD> there a  lot of good book. They have a lot of Microsoft press book. I 
  1280.  
  1281.  MD> even found  Undocumented windows in french (It was 100$! So i bought it 
  1282.  
  1283.  MD> in english (50$)).  They have a lot of good book... The active 
  1284.  MD> electronic book section is  shrinking. I thinq they wont sell book for 
  1285.  
  1286.  MD> long time....
  1287.  
  1288. Thanks a bunch Michel,
  1289.     I was unaware they had a programing section. It's a subject that is
  1290. dearly missing from most local libraries. I guess there are just not
  1291. enough serious programers in Quebec or we just don't advertise enough,
  1292. or maybe they don't advertise enough. I know I often thought of asking
  1293. such a library to try a programming section. I thought if it was
  1294. advertised enough, meaning just a bit, programers would come there by
  1295. the ton. After all, how many other libraries advertise programming
  1296. sections??
  1297.  
  1298.         Best regards,
  1299.         Mark Ouellet.
  1300.  
  1301.  
  1302. --- QM v1.30 
  1303.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1304.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1305.  
  1306. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1307.  
  1308. Conference 4
  1309. Date       01-12-93 03:35:00
  1310. From       Mark Ouellet
  1311. To         Dj Murdoch
  1312. Subject    Re: Borland Canada address?
  1313.  
  1314.  
  1315.     On 09-Jan-93, you, Dj Murdoch, of 1:249/99.5 wrote...
  1316.  
  1317.  DM> Minor correction:  Borland has no integrated debugging in protected 
  1318.  DM> mode.  The Windows IDE can't debug, and the DOS IDE can't debug pmode 
  1319.  
  1320.  DM> programs.  You *have to* use the Windows or pmode version of the 
  1321.  DM> debugger.
  1322.  
  1323. Oops there I go again ;-)
  1324.  
  1325.  DM> Something important that I've just found is missing:  no Asciiz binary
  1326.  DM> I/O.  WriteLn handles the PChars fine, but it's a pain to read a 
  1327.  DM> null-terminated string from a binary file or a stream.
  1328.  
  1329. Dj,
  1330.     Do what I do, Just read it in a buffer large enough to accomodate
  1331. it. I just used this method a few days ago to write a .MSG reader. I
  1332. simply declared a Structure of nearly 64K with the MSG header at the top
  1333. and a null terminated string as the last item. Read that in a buffer
  1334. just as big and had no problems.
  1335.  
  1336.         Best regards,
  1337.         Mark Ouellet.
  1338.  
  1339.  
  1340. --- QM v1.30 
  1341.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1342.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:24
  1343.  
  1344. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1345.  
  1346. Conference 4
  1347. Date       01-12-93 08:12:00
  1348. From       Mark Ouellet
  1349. To         Chris Gahan
  1350. Subject    Re: ..
  1351.  
  1352.  
  1353.     On 05-Jan-93, you, Chris Gahan, of 1:259/423.0 wrote...
  1354.  
  1355.  MO>> Mike,
  1356.  MO>> do you have any code to add SoundBlaster support to a BBS??? ;-)
  1357.  
  1358.  CG> HEY! You just gave me a good idea! Make a BBS and a Term prog, that can 
  1359.  
  1360.  CG> have
  1361.  CG> soundblaster, and grx support! Sort of like RoboTerm with soundblaster! 
  1362.  
  1363.  CG> Wow!
  1364.  CG> cool.. i'll get started as soon (as i learn more Pascal!) ... :) ok.. 
  1365.  
  1366.  CG> well,
  1367.  CG> thanks for the inspiration!
  1368.  
  1369. Chris,
  1370.     I just hope Mike doesn't see this or he'll kill me for sure ;-)
  1371.  
  1372.         Best regards,
  1373.         Mark Ouellet.
  1374.  
  1375.  
  1376. --- QM v1.30 
  1377.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1378.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:25
  1379.  
  1380. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1381.  
  1382. Conference 4
  1383. Date       01-12-93 11:28:00
  1384. From       Mark Ouellet
  1385. To         Patrick Drouin
  1386. Subject    Re: BP 7.0 UTILITIES (BO
  1387.  
  1388.  
  1389.     On 09-Jan-93, you, Patrick Drouin, of 1:240/1.0 wrote...
  1390.  
  1391.  PD> Did you know that the Camelot in Mtl accepts phone orders and I believe 
  1392.  
  1393.  PD> 
  1394.  PD> they also do 24hours delivery tp QCity? Give them a call for their 
  1395.  PD> catalog.
  1396.  
  1397. Well you see Patrick,
  1398.     Douglas allready gave me Camelot's adress and number some time ago
  1399. and I still have it around. But, I like to have a look first at the
  1400. book, heck I've been disapointed in books that looked great at first
  1401. glance so you can imagine I don't really like ordering books. I don't
  1402. think you buy records without having heard them at least once, right??
  1403.  
  1404.     Even local stores will order books for you but I still need to go
  1405. through it first to make sure it satisfies my needs. Come to think of it
  1406. the P.U.L used to have some good ones. It's been a while since I checked
  1407. their collection. I think I'll drop-by there in the near future just to
  1408. check on the current selection.
  1409.  
  1410.         Best regards,
  1411.         Mark Ouellet.
  1412.  
  1413.  
  1414. --- QM v1.30 
  1415.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1416.  * Tossed by SFToss/286 v1.02a on 93/01/14  23:38:25
  1417.  
  1418. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1419.  
  1420. Conference 4
  1421. Date       01-14-93 19:55:00
  1422. From       Trevor Carlsen
  1423. To         Mike Copeland
  1424. Subject    A better way?
  1425.  
  1426.  
  1427.  
  1428.  MC> Following is some code I've thrown together <!>, which has
  1429.  MC> to find a sequence of 4 characters in a large buffer -
  1430.  MC> non-text data.  The buffer is 4096 characters, and the
  1431.  MC> sequence(s) I'm searching for could be anywhere in it, and
  1432.  MC> may be found numerous times. I suspect this code is pretty
  1433.  MC> inefficient, but I can't think of anything better. (Yep,
  1434.  MC> this is to work with the ZIP directory at the end of the
  1435.  MC> file...) So, I'm looking for a better way to code this
  1436.  MC> process.
  1437.  
  1438. Mike, I think that I remember you indicating that you have TCSEL*.*.  If so
  1439. you already have an example from that package in the program SEARCH.PAS. 
  1440. This program is one of the few complete "bullet-proof" programs in the package
  1441. and is approaching what I call commercial grade.  As such it should be ideal
  1442. for your needs.
  1443.  
  1444. If I am mistaken and you don't have TCSEL*.* then it is available on PDN nodes.
  1445.  
  1446. TeeCee
  1447.  
  1448.  
  1449.  
  1450. --- TC-ED   v2.01  
  1451.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1452.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:15
  1453.  
  1454. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1455.  
  1456. Conference 4
  1457. Date       01-14-93 20:01:00
  1458. From       Trevor Carlsen
  1459. To         Brian Dhatt
  1460. Subject    Moderation
  1461.  
  1462.  
  1463.  
  1464.  DN> @PATH: 120/125 102 11/3 13/13 396/1 123/19
  1465.  
  1466.  BD> Dean, I imagine that you are one of these systems.  Your
  1467.  BD> re-echoing of many messages with the from field replaced
  1468.  BD> with your name is a problem.  Please fix it...Brian
  1469.  
  1470. You would be welcome to send this message by netmail.  However as you are
  1471. not the moderator this should not have been posted by you.  Self-appointed
  1472. echo cops do not enhance the echo in any way. 
  1473.  
  1474. If you wish to reply to this message you are to do so ONLY by netmail.
  1475.  
  1476. Moderator.
  1477.  
  1478. --- TC-ED   v2.01  
  1479.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1480.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:15
  1481.  
  1482. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1483.  
  1484. Conference 4
  1485. Date       01-14-93 20:07:00
  1486. From       Trevor Carlsen
  1487. To         Chris Priede
  1488. Subject    ORD and CHR not Function
  1489.  
  1490.  
  1491.  
  1492.  TC> Is that so?  My manual says it is a function and that is
  1493.  TC> good enough for me. No way is it an operator.  Actually chr,
  1494.  TC> ord, sizeof etc are not true functions in the sense that
  1495.  TC> they are called in the program, rather they are evaluated at
  1496.  TC> compile time and the appropriate action taken directly.
  1497.  
  1498.  CP> Yes, and that is the problem. Well, I will just have to show
  1499.  CP> your manual is wrong.
  1500.  
  1501. Does this mean that you now consider yourself a greater authority than Jensen
  1502. and Wirth also? 
  1503.  
  1504. I agree that if you define a function as a routine that is called at runtime
  1505. - eg control switches to another area of code before returning with a value,
  1506. then these are not functions.  However that is a narrow and not necessarily
  1507. correct (or incorrect) definition.
  1508.  
  1509. Many optimising compilers (and I do not claim that TP is any great shakes
  1510. in that field) do compile time evaluation of code where possible.  That does
  1511. not mean that ord and chr are not functions.
  1512.  
  1513. TeeCee
  1514.  
  1515. --- TC-ED   v2.01  
  1516.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1517.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:15
  1518.  
  1519. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1520.  
  1521. Conference 4
  1522. Date       01-14-93 20:24:00
  1523. From       Trevor Carlsen
  1524. To         Ross Tracy
  1525. Subject    Problem
  1526.  
  1527.  
  1528.  
  1529.  RT> I am also having problems with LongInt, I have a variable in
  1530.  RT> record declared as LongInt, and whenever I add any value to
  1531.  RT> it, as soon as it exceeds 32767, it screws up and gives a
  1532.  RT> random number.  Aren't LongInts supposed to be from -2b to
  1533.  RT> about 2billion???
  1534.  
  1535. Cast the first or second operand as a longint and your problem will disappear.
  1536.  eg...
  1537.  
  1538. var
  1539.   L      : longint;
  1540.   a,b,c  : integer;
  1541.  
  1542. begin
  1543.   a := 10000;
  1544.   b := 20000;
  1545.   c := 10000;
  1546.   L := a + b + c; { will ALWAYS return 25536  ( -32768 + (40000 - 32768)) }
  1547.  
  1548.   L := longint(a) + b + c;  { will correctly return 40000 }
  1549. end.
  1550.  
  1551. Expressions are evaluated in the same type as the operands.  I can assure
  1552. you that the results you are seeing are in no way random.  They may appear
  1553. that way if you do not understand what is happening.
  1554.  
  1555. TeeCee
  1556.  
  1557.  
  1558.   
  1559.  
  1560. --- TC-ED   v2.01  
  1561.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1562.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:15
  1563.  
  1564. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1565.  
  1566. Conference 4
  1567. Date       01-14-93 20:26:00
  1568. From       Trevor Carlsen
  1569. To         Ross Tracy
  1570. Subject    hey!
  1571.  
  1572.  
  1573.  
  1574.  RT> ... and I want to enter a field of a integer. but when
  1575.  RT> return is pressed, it Returns to the next line until proper
  1576.  RT> input is received (a number) I want to stop this and also
  1577.  RT> limit the length of the number to 4 chars..  so the input
  1578.  RT> field is 4 chars long and cannot be exceeded, and if Enter
  1579.  RT> is pressed, it won't go to the next line.
  1580.  
  1581. Get TCSEL003.* from a PDN node near you.  It has code that will do what you
  1582. want.  Be sure that you get 003 and not 002 or 001 as the routine you need
  1583. has a serious bug in those earlier releases.
  1584.  
  1585. TeeCee
  1586.  
  1587.  
  1588.  
  1589. --- TC-ED   v2.01  
  1590.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1591.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:15
  1592.  
  1593. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1594.  
  1595. Conference 4
  1596. Date       01-14-93 20:30:00
  1597. From       Trevor Carlsen
  1598. To         Doug Coker
  1599. Subject    Encryption
  1600.  
  1601.  
  1602.  
  1603.  DC> I need some encryption routines that could work with strings.
  1604.  
  1605. The following very simple routine will encrypt and decrypt a text file a line
  1606. at a time.  The CR/LF is left unencrypted and the algorithm ensures that no
  1607. encrypted character can be < asciiz 127 *provided that* the text for encrypting
  1608. has no hi-bit characters.
  1609.  
  1610. Obviously this is just a skeleten example (untested) with no error checking
  1611. but it should demonstrate what you need to do. After encrypting text just
  1612. reverse the parameters and run the program again to decrypt the encrypted text.
  1613.  
  1614.  
  1615. program encrypt_text;
  1616.  
  1617. var
  1618.   inText,
  1619.   outText  : text;
  1620.   st       : string;
  1621.  
  1622. function ConvertTxt(s: string): string;
  1623.   var x : byte;
  1624.   begin
  1625.     ConvertTxt[0] := s[0];
  1626.     for x := 1 to length(s) do
  1627.       ConvertTxt[x] := chr(ord(s[x]) xor (Random(128) or 128));
  1628.   end;  { ConvertTxt }
  1629.    
  1630. begin
  1631.   RandSeed  := 1234567;{ set to whatever value you wish - this is your "key" }
  1632.  
  1633.   assign(inText,ParamStr(1));
  1634.   reset(inText);
  1635.   assign(outText,ParamStr(2));
  1636.   rewrite(outText);
  1637.   while not eof(inText) do begin
  1638.     readln(inText,st);
  1639.     writeln(outText,ConvertTxt(st));
  1640.   end;
  1641.   close(inText);
  1642.   close(outText);
  1643. end.
  1644.  
  1645. TeeCee
  1646.  
  1647. --- TC-ED   v2.01  
  1648.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1649.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:16
  1650.  
  1651. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1652.  
  1653. Conference 4
  1654. Date       01-14-93 20:38:00
  1655. From       Trevor Carlsen
  1656. To         John Linden
  1657. Subject    Timer TSR
  1658.  
  1659.  
  1660.  
  1661.  JL> I would like to create a program that will execute another
  1662.  JL> program at a specified time. Would I have to make it a TSR??
  1663.  JL> If so, is there a lot of special things would have to do to
  1664.  JL> create a TSR??
  1665.  
  1666. Writing TSRs is not something for programming tyros.  Seasoned professional
  1667. programmers who earn their living in the industry generally prefer to use
  1668. pre-written library code. 
  1669.  
  1670. The gotchas and pitfalls of TSR writing for all but the elite are just too
  1671. many and it is easier, more productive and less painful to use code written
  1672. by specialists in the field.
  1673.  
  1674. If you still want to learn how to do them buy a good book - say Tischer's
  1675. "Turbo Pascal Internals" and a good professional grade TSR library - say TurboPo
  1676. er's "TSRs Made Easy" and study how the experts do it.
  1677.  
  1678. TeeCee
  1679.  
  1680.  
  1681.  
  1682. --- TC-ED   v2.01  
  1683.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1684.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:16
  1685.  
  1686. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1687.  
  1688. Conference 4
  1689. Date       01-15-93 06:02:00
  1690. From       Trevor Carlsen
  1691. To         John Linden
  1692. Subject    BBS Online Interface
  1693.  
  1694.  
  1695.  
  1696.  JL> This is off-topic but I'll help you real quick...
  1697.  JL> Sorry, guys for being off-topic. Won't do it again for a long time 
  1698.  
  1699. Strike 2
  1700.  
  1701. Moderator.
  1702.  
  1703. --- TC-ED   v2.01  
  1704.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1705.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:16
  1706.  
  1707. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1708.  
  1709. Conference 4
  1710. Date       01-14-93 07:44:00
  1711. From       Dj Murdoch
  1712. To         Trevor Robinson
  1713. Subject    Re: Real Number Arithmetic
  1714.  
  1715.   -=> Quoting Jason Huebel to All <=-
  1716.  
  1717.  JH> Also, How would I randomize a number between 1 and a number such as
  1718.  JH> 100,000? Integers only work up to 32767, so how would I go about it?
  1719.  
  1720.  TR> Well, how about Random(1000) * Random(100)?  Not 
  1721.  TR> scientific but it should be
  1722.  TR> okay.
  1723.  
  1724. That'll give a pretty non-uniform distribution on 0..65535; you could get
  1725. the uniform distribution by 
  1726.  
  1727.    Random(100)*longint(1000) + Random(1000);
  1728.  
  1729.  
  1730. --- Msg V3.2
  1731.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1732.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:19
  1733.  
  1734. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1735.  
  1736. Conference 4
  1737. Date       01-14-93 07:46:00
  1738. From       Dj Murdoch
  1739. To         martin nilsson
  1740. Subject    Re: tpu6->tpu7
  1741.  
  1742.   > I've never written any utility capable of doing that.  It's
  1743.  > actually much harder than you suggest; calls to the system
  1744.  > unit (and there are lots of them in normal code) can't be
  1745.  > made from assembly, so that complicates things a lot.
  1746.  
  1747.  MN> but the question is: is it all possible?  You only state 
  1748.  MN> that it "complicates things a lot", but to what degree?
  1749.  
  1750. To the degree that I've never done it.
  1751.  
  1752. --- Msg V3.2
  1753.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1754.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:19
  1755.  
  1756. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1757.  
  1758. Conference 4
  1759. Date       01-14-93 07:48:00
  1760. From       Dj Murdoch
  1761. To         Mark Ouellet
  1762. Subject    Re: Borland Canada address?
  1763.  
  1764.   DM> Something important that I've just found is missing:  
  1765.  MO> no Asciiz binary
  1766.  DM> I/O.  WriteLn handles the PChars fine, but it's a pain to read a 
  1767.  DM> null-terminated string from a binary file or a stream.
  1768.  
  1769.  MO> Dj,
  1770.  MO>     Do what I do, Just read it in a buffer large enough to accomodate
  1771.  MO> it. I just used this method a few days ago to write a .MSG reader. I
  1772.  MO> simply declared a Structure of nearly 64K with the MSG header at the top
  1773.  
  1774.  MO> and a null terminated string as the last item. Read that in a buffer
  1775.  MO> just as big and had no problems.
  1776.  
  1777. That's fine because you know how big to make the buffer - the file size is
  1778. the buffer size.  I'm reading .TPH files, where every line is null-terminated,
  1779. and there's no guarantee that a line will be reasonably short.  I have to
  1780. handle the possibility that a line won't fit in the buffer I choose, since
  1781. I don't want to allocate 64K to every line.  Grrrr.  Why didn't they just
  1782. use Pascal strings?? 
  1783.  
  1784.  
  1785. --- Msg V3.2
  1786.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1787.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:19
  1788.  
  1789. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1790.  
  1791. Conference 4
  1792. Date       01-13-93 23:03:00
  1793. From       Mark Ouellet
  1794. To         John Reid
  1795. Subject    Re: BP 7.0 Utilities (Bo
  1796.  
  1797.  
  1798.     On 10 Jan 93 , you, John Reid, of 1:150/170.0 wrote...
  1799.  
  1800.  JR> You need to know someone who has paid the US$7.95 for basic
  1801.  JR> services and you need a credit card. Order to delivery is often
  1802.  JR> within two days. Of course, browsing is difficult.
  1803.  
  1804. John,
  1805.     It all seems interresting but your last comment is what is
  1806. effectively holding me back. I allready received a similar message about
  1807. Camelot in Montreal, they will also deliver to Quebec City but again you
  1808. can't browse first. Thanks I'll keep the info anyway just in case.
  1809.  
  1810.         Best regards,
  1811.         Mark Ouellet.
  1812.  
  1813.  
  1814. --- QM v1.30 
  1815.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1816.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  1817.  
  1818. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1819.  
  1820. Conference 4
  1821. Date       01-13-93 23:06:00
  1822. From       Mark Ouellet
  1823. To         Scott Samet
  1824. Subject    Re: move()
  1825.  
  1826.  
  1827.     On 10 Jan 93 , you, Scott Samet, of 1:135/990.0 wrote...
  1828.  
  1829.  SS> All you have to do is keep in mind that under DPMI, memory management is 
  1830.  
  1831.  SS> almost exactly the same as under Windows enhanced mode. Use the memory 
  1832.  
  1833.  SS> management chapters of Petzold's Windows book as a guideline.
  1834.  
  1835. Scott,
  1836.     Thanks, I was aware of that as the DPMI server of Qemm lists this.
  1837. They state that if Windows is started QDPMI will relinquish DPMI support
  1838. to Windows but other applications requiring DPMI services that don't
  1839. have their own like Windows does will be serviced by QDPMI.
  1840.  
  1841.         Best regards,
  1842.         Mark Ouellet.
  1843.  
  1844.  
  1845. --- QM v1.30 
  1846.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1847.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  1848.  
  1849. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1850.  
  1851. Conference 4
  1852. Date       01-13-93 23:08:00
  1853. From       Mark Ouellet
  1854. To         Vince Laurent
  1855. Subject    Re: BP 7.0 Utilities (Bo
  1856.  
  1857.  
  1858.     On 10 Jan 93 , you, Vince Laurent, of 1:382/10.0 wrote...
  1859.  
  1860.  VL> The book stores around here are pretty good.  If they don't have one
  1861.  VL> they order it.  I also belong to the Small Computer Book club.  If they
  1862.  VL> have a book I want and the book store doesn't have it (or would take too
  1863.  
  1864.  VL> long to order it) I get it through there at a reasonable cost.
  1865.  
  1866. Vince,
  1867.     Thanks but see my other two replies. Again my main concern is not
  1868. being able to browse through the book first.
  1869.  
  1870.         Best regards,
  1871.         Mark Ouellet.
  1872.  
  1873.  
  1874. --- QM v1.30 
  1875.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1876.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  1877.  
  1878. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1879.  
  1880. Conference 4
  1881. Date       01-13-93 23:08:00
  1882. From       Mark Ouellet
  1883. To         Robert Jambor
  1884. Subject    Re: Speed wanted !
  1885.  
  1886.  
  1887.     On 10 Jan 93 , you, Robert Jambor, of 3:640/521.64 wrote...
  1888.  
  1889.  RJ> Why not write it in assembler then, if you are going to all this
  1890.  RJ> trouble ?? Just write the functions as externals.
  1891.  
  1892. Robert,
  1893.     That was the idea!! since BASM can't support 386 instructions it has
  1894. to be in another form.
  1895.  
  1896.         Best regards,
  1897.         Mark Ouellet.
  1898.  
  1899.  
  1900. --- QM v1.30 
  1901.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1902.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  1903.  
  1904. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1905.  
  1906. Conference 4
  1907. Date       01-13-93 23:17:00
  1908. From       Mark Ouellet
  1909. To         Brian Swanson
  1910. Subject    Re: 2 Questions
  1911.  
  1912.  
  1913.     On 09 Jan 93 , you, Brian Swanson, of 1:123/419.0 wrote...
  1914.  
  1915.  >> 2)  What the structure format is for netmail *.MSG
  1916.  >> files??
  1917.  
  1918.  BS> --- Cut Here ---
  1919.  BS> 
  1920.  BS> Type
  1921.  BS> Fido_FromType    = String[35];
  1922.  BS> Fido_ToType      = String[35];
  1923.  BS> Fido_SubType     = String[71];
  1924.  BS> Fido_DateType    = String[19];
  1925.  
  1926. Brian,
  1927.     All of the above are incorrect!!!!! These are not strings they are
  1928. arrays of caracters which is not the same.
  1929.  
  1930.         Best regards,
  1931.         Mark Ouellet.
  1932.  
  1933.  
  1934. --- QM v1.30 
  1935.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1936.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  1937.  
  1938. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1939.  
  1940. Conference 4
  1941. Date       01-13-93 23:32:00
  1942. From       Mark Ouellet
  1943. To         Glenn Crouch
  1944. Subject    Re: Strange Key Happenings in BP IDE
  1945.  
  1946.  
  1947.     On 09 Jan 93 , you, Glenn Crouch, of 3:690/643.3 wrote...
  1948.  
  1949.  GC> Well Peter Ogden and myself managed to locate one package that was 
  1950.  GC> causing droppings and keystrokes to not work while in the BP IDE, and 
  1951.  
  1952.  GC> that was QDPMI - the DPMI extension for QEMM.  It caused great havock 
  1953.  
  1954.  GC> with the new PKZIP 2.04c as well.  Thankfully Quarterdeck has released 
  1955.  
  1956.  GC> an update - QDPMI101 - which seems to fix not only the problems with 
  1957.  
  1958.  GC> PKZIP but also BP!!!
  1959.  
  1960. Glenn,
  1961.     I had been running Qdpmi for a few months and had no problems with
  1962. BP at all!! Of course I'm running a 486-33 if that makes a difference.
  1963.  
  1964.         Best regards,
  1965.         Mark Ouellet.
  1966.  
  1967.  
  1968. --- QM v1.30 
  1969.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  1970.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  1971.  
  1972. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1973.  
  1974. Conference 4
  1975. Date       01-14-93 06:14:00
  1976. From       Mark Ouellet
  1977. To         Mike Copeland
  1978. Subject    Re: IDE
  1979.  
  1980.  
  1981.     On 10 Jan 93 , you, Mike Copeland, of 1:114/18.10 wrote...
  1982.  
  1983.  mj>>I see that 'M' once in a while and I asked the same question in the 
  1984.  mj>>Borland forum on Compuserve... no one could tell me what it is or 
  1985.  mj>> why it 
  1986.  mj>>appears but others have confirmed seeing it too.
  1987.  
  1988.  MC> Richard Nelson just posted an answer: it's a "modify file" indicator, 
  1989.  
  1990.  MC> and this information escaped the Borland documentation process...
  1991.  
  1992. Mike,
  1993.     Are you sure about this?? Mine displays the graphic star, you know
  1994. the one that looks more like a daisy?? It appears as soon as I modify
  1995. the file.
  1996.  
  1997.         Best regards,
  1998.         Mark Ouellet.
  1999.  
  2000.  
  2001. --- QM v1.30 
  2002.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  2003.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  2004.  
  2005. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2006.  
  2007. Conference 4
  2008. Date       01-14-93 10:55:00
  2009. From       Mark Ouellet
  2010. To         Francois Thunus
  2011. Subject    Re: TCSEL003: ReadTxt
  2012.  
  2013.  
  2014.     On 08 Jan 93 , you, Francois Thunus, of 2:270/25.1 wrote...
  2015.  
  2016.  FT> I have only quoted this part of the message but i think there is
  2017.  FT> a big misunderstanding. I have more than 500k of memory available (when
  2018.  FT> inside the program) and i really don't think that is the problem. I have
  2019.  FT> trapped the loop as i always do when i don't understand what is going
  2020.  FT> on, using simply a........
  2021.  
  2022.  FT> PS: i still don't get it, though :*)
  2023.  
  2024. Francois,
  2025.     You mentioned the file size further down in your message. Now
  2026. remember that having 500K free does not garantee loading a 200K text
  2027. file. if you are using an array of string pointers for instance, you are
  2028. still limited to 64k for that array, and it will contain at most 16380
  2029. pointers. Which means if the 200K file only contains short strings, say
  2030. 2 or 3 caracters each, then you get 200000/5 (3 caracter + CR+LF=5)=
  2031. 20000 pointers needed for 20000 different strings.
  2032.  
  2033. Maybe that is what was happening to you.
  2034.  
  2035.         Best regards,
  2036.         Mark Ouellet.
  2037.  
  2038.  
  2039. --- QM v1.30 
  2040.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  2041.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  2042.  
  2043. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2044.  
  2045. Conference 4
  2046. Date       01-14-93 10:59:00
  2047. From       Mark Ouellet
  2048. To         Wayne Moses
  2049. Subject    Re: Borland Canada address?
  2050.  
  2051.  
  2052.     On 11 Jan 93 , you, Wayne Moses, of 1:255/6.0 wrote...
  2053.  
  2054.  WM> That is a good idea ... never thought of it like that. Of course, there
  2055.  WM> must be a need for additional credit other than getting all student
  2056.  WM> upgrade prices on various software packages. If not then the cost of 
  2057.  
  2058.  WM> the
  2059.  WM> course(s) must be added to the student upgrade price. That can come out
  2060.  WM> more expensive, depending on what you take.
  2061.  
  2062.     That's why I mentioned the need for those extra credits. If you
  2063. don't need any credit then the total cost effectively outways the normal
  2064. cost.
  2065.  
  2066.         Best regards,
  2067.         Mark Ouellet.
  2068.  
  2069.  
  2070. --- QM v1.30 
  2071.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  2072.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  2073.  
  2074. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2075.  
  2076. Conference 4
  2077. Date       01-14-93 11:09:00
  2078. From       Mark Ouellet
  2079. To         Martin Austermeier
  2080. Subject    Re: Break & continue
  2081.  
  2082.  
  2083.     On 11 Jan 93 , you, Martin Austermeier, of 2:2407/109.15 wrote...
  2084.  
  2085.  DM>> Can you post an example where you think a Goto would be the best 
  2086.  DM>> choice?
  2087.  
  2088.  MA> in nested loops for instance.
  2089.  MA> 
  2090.  MA> like in
  2091.  MA> 
  2092.  MA> FOR i := 1 TO 100 DO BEGIN
  2093.  MA>    FOR j := 1 TO 100 DO BEGIN
  2094.  MA>        FOR k := 1 TO 100 DO BEGIN
  2095.  MA>            IF condition THEN GOTO END_LOOPS;  { rather than Break }
  2096.  MA>        END;
  2097.  MA>    END;
  2098.  MA> END;
  2099.  MA> END_LOOPS:
  2100.  
  2101. Now see Martin,
  2102.     there is a BAD example. You can't figure it out without a GOTO
  2103. simply because your logic is in error. Goto is not the solution, the
  2104. solution is to use the correct construct in the correct situation.
  2105.  
  2106.     i := 1;
  2107.     condition := false;
  2108.     while (i <= 100) and not condition do begin
  2109.         j := 1;
  2110.         while (j <= 100) and not condition do begin
  2111.             k := 1;
  2112.             while (k <= 100) and not condition do begin
  2113.                 inc(k);
  2114.             end;
  2115.             inc(j);
  2116.         end;
  2117.         inc(i);
  2118.     end;
  2119.  
  2120.     As you can see, there is allmost allways a logic solution which
  2121. maintains normal flow.
  2122.  
  2123.         Best regards,
  2124.         Mark Ouellet.
  2125.  
  2126.  
  2127. --- QM v1.30 
  2128.  * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
  2129.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:26
  2130.  
  2131. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2132.  
  2133. Conference 4
  2134. Date       01-15-93 00:11:00
  2135. From       Norbert Igl
  2136. To         Mike Copeland
  2137. Subject    Pascal -> COM?
  2138.  
  2139.  
  2140.  
  2141.  
  2142. Hello Mike!
  2143.  11 Januar 1993 20:29, Mike Copeland wrote to Chris Gahan:
  2144.  
  2145.  CG>> Is there a way to make Pascal compile with a COM file
  2146.  CG>> instead
  2147.  CG>> of an EXE? Com files are faster if all you're using is text and they
  2148.  CG>> are smaller most of the time.. so, is there a way?
  2149.  
  2150.  MC>    No, there isn't any way to get TP/BP to produce .COM files.  I think
  2151.  
  2152.                     ------------------------------------------
  2153.  
  2154.    .... quoteing J.Bond :  "Never say never" ....
  2155.  
  2156.  
  2157.   [BIG GRIN ON...]
  2158.  
  2159.  
  2160.   Var   F : File;
  2161.   Const Comfile : array[0..4] of Byte = ($EA,$00,$00,$FF,$FF);
  2162.   begin
  2163.     assign(f,'RESET.COM');
  2164.     rewrite(f, sizeof(comfile) );
  2165.     blockwrite( f, Comfile, 1 );
  2166.     Close( f );
  2167.     writeln(' REBOOT.COM created !');
  2168.   end.
  2169.  
  2170.   sorry, could't resist.....Norbert ( Not writing an BBS....(:-))
  2171.  
  2172.  
  2173. --- GoldEd 2.40p/FD2.02/FastEcho
  2174.  * Origin: Fly like an Igl  (2:2402/300.3)
  2175.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:31
  2176.  
  2177. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2178.  
  2179. Conference 4
  2180. Date       01-14-93 23:22:00
  2181. From       Norbert Igl
  2182. To         Vince Laurent
  2183. Subject    MultiLine Question
  2184.  
  2185.  
  2186.  
  2187.  
  2188. Hello Vince!
  2189.  
  2190. Dienstag, 12 Januar 1993 12:27, Vince Laurent wrote to All:
  2191.  
  2192.  VL> BEGIN
  2193.  VL>   Assign(GameFile,'GIP.DAT');
  2194.  VL>   {$I-} Reset(GameFile); {$I+}
  2195.  VL>   IF IOResult <> 0 THEN NumPlayers := 1
  2196.  VL>     ELSE BEGIN Readln(GameFile,NumPlayers); INC(NumPlayers); END;
  2197.  VL>   ReWrite(GameFile);
  2198.  VL>   Writeln(GameFile,NumPlayers);
  2199.  VL>   Close(GameFile);
  2200.  VL> END;
  2201.  
  2202.  VL> This works fine now and then but I have managed to get into the
  2203.  VL> situation where two people join the game almost at the same time
  2204.  VL> and instead of have 2 players, there is only 1.
  2205.  
  2206.    look at this theoret. timing-diagramm.....
  2207.  
  2208.   Action  |  player    #1          |          #2
  2209.           |                        |
  2210.  ---------+------------------------+-----------------------
  2211.           |           ?            |       ?
  2212.   Time    |        Assign(f)       |       ?
  2213.    |      |        Reset( f )      |   Assign( f)
  2214.    V      |        IoResult=1      |   Reset(F);
  2215.           |        1->NumPlayer    |   IoResult = 5     (* 162 ? *)
  2216.           |        Rewrite(f)      |   1-> NumPlayer
  2217.           |        write(f)        |   Rewrite( f )
  2218.           |        close (f);      |   write( f )       (* STILL = 1 *)
  2219.           |           ?            |   close ( f )
  2220.  ---------------------------------------------------------------
  2221.                           NumPlayer = 1 !
  2222.  
  2223.    the problem is "IoResult <>0" !
  2224.    you have to be more specific !
  2225.  
  2226.    "IoResult=2" ...  "noFile"
  2227.             =5  .... "file in Access"
  2228.         (162) .........." "
  2229.  
  2230.    something like this might work :
  2231.  
  2232.  assign(...);
  2233.  reset(...);
  2234.  repeat
  2235.    Case IoResult of
  2236.      0 : ;    { file OK and open FOR ME to read/write, locked for others ! }
  2237.  
  2238.      2 : ;    { no File, OK FOR ME to write, locked for others ! }
  2239.      else begin   { FILE alreday open by another process !!! }
  2240.        delay( random( 1000 ));
  2241.        Reset( GameFile );
  2242.        { debug output goes here ... }
  2243.      end;
  2244.    end { case }
  2245.  until ( IoResult = in [ 0,2 ]  );
  2246.  
  2247.   { here goes the reading/writing... }
  2248.  
  2249.  
  2250.  VL> How do I lock a single TEXT file from others?
  2251.  
  2252.  see above .
  2253.  
  2254.  VL> I also think this will be a problem area when I want to remove
  2255.  VL> players from the game.
  2256.  
  2257.  the same....
  2258.  
  2259.  VL> Any help would be GREATLY appreciated!
  2260.  
  2261.  yo're welcome (:-)   Norbert
  2262.  
  2263. --- GoldEd 2.40p/FD2.02/FastEcho
  2264.  * Origin: Fly like an Igl  (2:2402/300.3)
  2265.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:31
  2266.  
  2267. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2268.  
  2269. Conference 4
  2270. Date       01-14-93 23:48:00
  2271. From       Norbert Igl
  2272. To         jonny bergdahl
  2273. Subject    Tp:ultimate virus maker
  2274.  
  2275.  
  2276.  
  2277.  
  2278. Hello jonny!
  2279.  
  2280.   12 Januar 1993 14:53, jonny bergdahl wrote to Brian Pape:
  2281.  
  2282.  >> codes that I have written into something that CPAV (Central Point Anti-
  2283.  >> Virus) insists are viruses...  Other virus programs say the same thing-
  2284.  
  2285.  jb> CPAV is plain junk.
  2286.  
  2287.   (:-) i read a good orgin-line some time ago....
  2288.  
  2289.   ....  'Junk : Stuff we throw away. Stuff: Junk we keep."
  2290.  
  2291. Norbert
  2292.  
  2293. --- GoldEd 2.40p/FD2.02/FastEcho
  2294.  * Origin: Fly like an Igl  (2:2402/300.3)
  2295.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:31
  2296.  
  2297. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2298.  
  2299. Conference 4
  2300. Date       01-14-93 23:56:00
  2301. From       Norbert Igl
  2302. To         Scott Wolfe
  2303. Subject    unix/pascal
  2304.  
  2305.  
  2306.  
  2307. Hello Scott!
  2308.  
  2309. Dienstag, 12 Januar 1993 06:51, Scott Wolfe wrote to All:
  2310.  
  2311.  SW> Is it possible to write Pascal code to run in a Unix inviroment?
  2312.  SW>        -Scott Wolfe
  2313.  
  2314.   look for " linux " and " GNU C++ preprocessor for pascal ",
  2315.   i heard this  to be a ( nearly ? ) TP 5.0 compatible system.
  2316.  
  2317.   Norbert
  2318.  
  2319. --- GoldEd 2.40p/FD2.02/FastEcho
  2320.  * Origin: Fly like an Igl  (2:2402/300.3)
  2321.  * Tossed by SFToss/286 v1.02a on 93/01/16  07:53:31
  2322.